The invention relates to a method and apparatuses for selecting “early media” user data transmitted via at least one telecommunication network prior to termination of initiation of a call between a calling subscriber terminal and at least one called subscriber terminal.
The Session Initiation Protocol (SIP) is a signaling protocol that can be used for call control, for example, of telephone conversations. SIP is standardized by the IETF in RFC 3261 and in an older version in RFC 2543. To describe the switched communication connection, SIP uses the Session Description Protocol (SDP), IETF RFC 2327, in a manner described in IETF RFC 3264. SIP, together with the negotiated user connections, is usually transmitted using the Internet protocol. SIP is used in the above-described manner in, for example, the Internet Multimedia Subsystem (IMS) of a mobile radio network standardized by 3GPP or 3GPP2.
During initiation of a call from the SIP terminal of a caller A to a called user B, the SIP signaling can be redirected by switching nodes or “proxies”. The proxies are permitted to redirect an incoming message which presents a request by the user A for a connection to B (an INVITE request) to a plurality of other proxies or SIP terminals simultaneously or sequentially—for example, in order to search for the user B. Because the last-mentioned proxies can branch the message when redirecting it, a tree-like branching of the message can occur. This branched redirection of messages is referred to in SIP as “forking”.
When the INVITE message reaches a terminal of user B, this terminal can respond with what is called a “1xx provisional response” which can serve, for example, to negotiate the media (e.g. speech, video) used for the communication connections and their coding, or to indicate that the user B is being alerted (for example, by the ringing of his SIP telephone). In the event of forking, it can happen that a plurality of terminals send such provisional responses—for example, if a plurality of SIP telephones ring simultaneously. To conclude the initiation of the communication relationship between a terminal of caller A and a terminal of the called party B, the latter terminal responds with what is called a “2xx final response”, for example, when user B has unhooked the SIP telephone. A plurality of terminals of B may send such final responses, for example, if a plurality of ringing SIP telephones are unhooked. Accordingly, it can happen that the terminal of A receives provisional responses and/or final responses from a plurality of terminals of B. Each terminal of B provides all the messages it sends as responses to A with the same unique identification. If SIP response messages with a new identification reach the terminal of A, the terminal of A learns from this that it is communicating with a new terminal point. In this case the SIP refers to a “dialogue” existing between the terminal of A and the responding terminal of B. Before A (and/or B, if applicable) has received a final response for a dialogue, this is referred to as an “early dialogue”, the subsequent state as an “establish dialogue”.
It can happen that before the end of initiation of the communication relationship, the terminals of A and B exchange media (user data) which is referred to as “early media”. For example, as in a known telephone network, ring tones and announcements may be transmitted, preferably in the direction from B to A. For a telephone network with SIP signaling, support by an “early media” transmission is especially important if the network is connected to a conventional telephone network.
If a plurality of dialogues are established in (/with) terminal A during initiation of the communication relationship from A to B as a result of forking, A may also receive media (user data), in particular early media, from different terminals B, B′. The terminal of A must represent the media in a suitable fashion. For example, it is possible that different incoming video streams are displayed in separate windows on a display screen. Frequently, however, it is appropriate to select only one incoming media stream and to reject the remaining media streams—for example, because the display screen in a mobile terminal is too small to show a plurality of windows, or because the superposing of different ring tones or announcements would make the content unintelligible.
Information via the corresponding SIP dialogues might be criteria permitting the selection of a suitable media stream (user data stream) for representation:                If an early dialogue becomes an established dialogue through receipt of the first SIP final response, it is appropriate to select the corresponding media stream.        It may be appropriate to select the early media that corresponds to the early dialogue last established. This is especially the case if the proxies initiate forking in a sequential manner. If a terminal sends a negative response, or if after a given time the communication relationship with it has not been established, for example, because no user has “unhooked”, a proxy redirects the INVITE request to a different terminal. The IETF SIP WG is in the process of specifying methods which will enable terminal A to request a proxy to search only sequentially (draft-ietf-sip-callerprefs).        Terminal A can terminate dialogues using SIP signaling—for example, because it is able to support only a limited number of dialogues. The corresponding media may, however, continue to be received for a certain time because of the network delay times of signaling and media. It is desirable to suppress the media during this transition time.        
The information contained in SIP and SDP does not always unambiguously allow a SIP dialogue to be correlated with the corresponding media stream. In particular, the terminal of caller A selects an IP address and port, for example, a UDP port (see IETF RFC 768), to receive the media streams before it sends the INVITE request containing this information. All incoming media are therefore received at the same IP address and the same port. They can be distinguished by the parameters “source IP address” in the IP header and “source port” in the UDP header of the packets received, i.e. the IP address and the port from which the packets were sent. However, according to RFC 3264, no information on this source IP address and source port is contained in SIP/SDP, but only on the destination IP address and the destination port, i.e. the IP address and port to which the packets were sent.
When SIP forking was designed, the interaction with early media was at first not considered, since early media occur in a SIP network only in special cases, for example, in conjunction with a conventional telephone network.
The handling of early media (user data) in the case of forking is currently being discussed in the IETF SIPPING Working Group. The “draft-camarillo-sipping-early-media” draft proposes that separate communication connections for early media user data be negotiated using SIP, terminal B acting as caller in the communication connections for early media when it receives a call from A for the actual user connection and initially enters into an early dialogue regarding this call for the user connection with A. However, this has the disadvantage that considerably more SIP messages must be exchanged, leading to delay in initiating the call and higher resource demand, especially when transmitting via an air interface with narrow bandwidth. In addition, it might possibly be necessary to reserve separate transmission resources for early media and for the actual user connection.
In the “draft-ietf-mmusic-sdp-srcfilter” the IETF MMUSIC Working Group proposes to introduce into SDP a parameter which allows expression of the source IP address and the source UDP port from which a recipient wishes to receive packets. This information is useful in configuring interposed firewalls. However, the use of this parameter in H.248 signaling has not so far been described.